Commonly, pluralities of computers, databases, printers and other computing or computing related devices are often established in clusters, as members or elements of a network, or even as loosely defined connections (which may be permanent or temporary) of computers and/or computing devices. Such configurations shall hereafter collectively be identified as a Cluster. Similarly, those computing devices establishing the connections between and with other such devices shall be defined as Nodes. Further, it is commonly appreciated that various virtual and/or real devices and components are often utilized in and/or accessed by a computing device (for example, printers, hard drives, monitors, software applications and others). For purposes of the present discussion, such devices are herein identified as Resources. Such Resources are generally accessible and/or utilized via other systems and devices, and/or users of such systems and devices via Nodes on a Cluster. Such users (which may be human or automated) are herein collectively defined as Clients. As such, it is commonly appreciated that Clients, via Nodes on Clusters, often utilize and need information pertaining to all the Resources or specific types or instances of Resources accessible to the Client.
Since Clients often desire to know what type of Resources are accessible via a given Cluster, various software devices have been developed that enable Clients to obtain information pertaining to a Resource, a Node, a Cluster or a combination thereof. Such devices are often called Object Managers (OM). More specifically, standardized OMs have been developed, including for example, the Common Information Modeling standard (CIM). The CIM standard for OMs was created by a consortium of industry companies and can be found at http://www.dmtf.org. It is commonly appreciated that CIM and WBEM are extremely similar, as such CIM is herein defined to also include WBEM.
The CIM standard outlines the basic architecture for a CIM compliant OM (CIMOM) but does not enforce any implementation details. As is commonly appreciated, CIM enables application developers to code their Client's applications so that they may interact with the CIMOM using a predefined, platform independent, set of Application Program Interfaces (APIs). This basic CIM architecture enables a CIMOM to startup and load any CIM compliant Resource via a Provider, wherein a Provider is a piece of software code that will call whatever routines are needed to gather data in order to provide the necessary objects in a schema. Those skilled in the art appreciate that a schema is an abstraction of something that exists in the real world. As such, in CIM, a schema is a group of classes (collections or sets of objects) that have only one owner. For example, a collection of disc drives might have an owner identified as a specific database, i.e., a Resource, that is connected to the Cluster and is accessible via the associated Provider.
Each Provider is suitably configured to extract information from the various objects with which it may be associated. For example, in a multi-disc or tape database, a database Provider is configured to obtain necessary information from each object in the database. Such information might include available memory, file allocations, and other information. There are often hundreds if not thousands of Providers on a given Node and/or Cluster. Provider writers commonly come up with a schema of what they are going to provide, and then code their respective Providers to provide such objects upon request. The CIM standard defines those APIs utilized to interact and extract information from a Provider. These standards are utilized by Provider writers.
As such, it is to be appreciated that a pre-defined methodology exists for identifying information about a Resource, a group of Resources, or even a sub-set of a Resource to an OM under the CIM standard. Under these standards, each CIMOM is configured such that it can determine which Provider is providing the desired information (for example, the amount of available memory in a database). Further, the CIMOM is configured to “ask” for and receive such information from a Provider. However, the CIM standard does not specify how information from Providers is to be obtained. Since Cluster managers often desire Cluster-wide configuration and Resource information, an approach is needed to determine how Resources are configured on a Cluster using Providers and requests from CIMOMs.
One common methodology by which a Client CIM can obtain Cluster-wide information concerning Resources is shown in FIG. 1. As shown, this prior art process basically entails having the Client CIM contact every Node on the Cluster. As can be readily appreciated, this approach requires numerous connections between the requesting Client CIM 102 and a plurality of Node CIMOMs (110, 112, and 114) on Nodes A, B and C (104, 106 and 108, respectively). In turn, each of the Node CIMOMs, may have multiple Providers connected thereto (for example, Providers A and B, i.e., 116, 118, 120, 122, 124, and 126). For even a simple three Node example, where each Node possesses two Providers (as shown in FIG. 1), the request from the Client CIM 102 over the communications network 128 entails requests to three separate Node CIMOMs, which may end up requesting information from six Providers. In an extremely large system, wherein hundreds if not thousands of Nodes may exist, this approach can be extremely time and Resource consuming. This may be especially true when the Client CIM 102 can only contact one Node at a time and, thus, is forced to contact each Node on a Cluster in a serial manner. Further, since the network connection 128, in certain embodiments, may not be secure, this process may also entail numerous authorizations and authentication steps being performed with each request by the Client CIM 102 to a Node CIMOM (for example, one provided on Node A 104, Node B 106 or Node C 108). These authorizations may also create delays in the processing of the request and the operating efficiency of the Cluster as a whole. Therefore, the approach shown in FIG. 1 is often tedious and inefficient. This approach is often considered as operating at too high a level of abstraction and is therefore undesirable because of the burdens and inefficiencies it places upon the Client CIM 102 and the Cluster in general.
Another prior art approach often utilized to obtain information from Providers by a Client CIM 202 is shown in FIG. 2. This approach again begins with the Client CIM 202 establishing a connection via a communications network 228 with another Node (for example, Node B 206) on the Cluster. However, unlike the example shown in FIG. 1, for this embodiment only a single connection is established between the Client CIM 202 and a single Node (for example, Node B 206). In short, this approach does not require the Client CIM 202 to contact each and every Node on the Cluster. Instead, this approach utilizes Providers that are multi-node aware. One example of a multi-node aware Provider is provided in U.S. Patent Application Serial Number concurrently filed herewith, on Aug. 31, 2001, by Jim Curtis, et al. and entitled “An Application Container that Allows Concurrent Execution on Multiple Nodes in a Cluster”, the contents of which are herein incorporated, in their entirety, by reference.
As shown in FIG. 2, this second prior art method requires each Provider to include a data daemon (for example, data daemons 230, 232, 234, 236, 238 and 240). Each data daemon contains the appropriate software codes such that when a request from a single Provider (for example, Provider A 220 of Node B 206) is communicated to the various other Nodes on the Cluster, each corresponding data daemon (for example, data daemon A 230 on Node A, or data daemon A 234 on Node B 206, or data daemon A 238 on Node C) provides the requested information, when available. In this prior art embodiment, every Provider, and thus every data daemon, must be Cluster-aware.
Noticeably, even the requesting Node (Node B 206) contains data daemons 234 and 236 from which configuration information may be needed. Further, this approach requires each Provider to be capable of contacting other Providers on the Cluster. Since certain applications may not provide Cluster-aware Providers, this approach may be of limited applicability. Further, instead of having the Client contact every Node on the Cluster, this approach merely reduces the decision/contacting processes to the Provider level. Further, this approach requires every Provider to be capable of multiplexing requests to every other Node on the Cluster. As such, this approach reduces the level of abstraction to too low a level and requires every Provider to possess capabilities previously provided by the requesting Client CIM, as shown in FIG. 1. Therefore, a new system and methodology for obtaining information from a Provider is needed which does not place the burden for determining information about Resources on a Cluster at either the Client CIM (i.e., too high of a level of abstraction) or at the Provider level (i.e., too low of a level of abstraction).